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SECURE GAME DOWNLOAD 

FIELD OF THE INVENTION 

This invention relates generally to the jSeld of casino gaming terminals, gaming 
kiosks and lottery gaming terminals. 

DESCRIPTION OF THE RELATED ART 

On-line download of updated software and new games has been performed 
routinely with lottery terminals since the on-line capture of lottery slips started to be 
deployed in the late 1980s. The techniques and procedures have been refined along the 
years and are now considered as essential features. On the other hand, casino regulators 
have always been reluctant to introduce on-line download of updated softwaire and of 
new games for casino gaming machines. Such reluctance stems from concerns relative to 
unauthorized intrusion and malicious modification of software code. These concerns are 
understandable, particularly since the late 1990s because of the general trend of 
constructing gaming terminals using standard PC hardware and PC software platforms 
that are subject to assault by hackers that are well versed in the techniques for taking 
advantage of the known weaknesses and flaws of such platforms. Even now with 
lotteries, the appeal of making use of the broadband public Intemet network instead of 
private networking is considerable, but there are indeed significant security concerns and 
consequently new plans are blurred with uncertainty. 

Although specialized download utilities and software update utilities such as 
Windows Installer, InstallShield and GetRight include data integrity verification 
mechanisms to ensure that the downloaded code is not corrupted, there is no mechanism 
to ensure that the code has not been tampered with. While secure Intemet software 
download technologies such as Authenticode employ powerful PKI (Public Key 
Infrastructure) code signing, there is no fail-proof mechanism to ensure that the code has 
not been tampered with at a later stage. Once an authorized properly signed software 
module has started execution, the operating system does not provide means to verify if 
the code loaded in memory has not been tampered with to execute firaudulent operations. 

Although software corporations hke Microsoft have lately shifted their 
development focus to making their software more stable and very seciure, there is always 
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the risk that an iinknown bug or a back door exists somewhere amongst the millions lines 
of code that would allow someone to perpetrate some form of cheat. Hidden back-doors 
might be mandated by the United States' NSA (National Security Agency) to be 
incorporated in operating systems to enable them to monitor tOTorism and drug 

5 trafEicking. Consequently, some corrupt employees or ex-employees having inner 

knowledge of &es6 back door accesses might be tempted to fraudul^tly exploit such 
inner knowledge. Microsoft operating systems and other modem operating systems such 
as Linux are too complex and constantly changing to consider comprehensive 
certification by labs traditionally trusted by game regulators for certifying gaming 

10 products made by gaming equipment vendors. 

Moreover, using strong PKI code signing techniques does not guaranty that the 
code can be trusted once verified because the "verifying" tool, or the tool that verifies the 
verifying tool (and so on. . .) may itself not be trusted. 

The approach of the Trusted Computing Platform Alliance (TCP A), whose 

15 specification was finalized in January 2001, calls for the creation of a Trusted Platform 

Module (TPM) that requires a discrete cryptographic processor residing on the PC's 
motherboard that contains a xmique digital signature. Microsoft's security initiative code 
named "Palladium", on the other hand, uses new forthcoming hardware security features 
built directly into microprocessors and supporting chipsets being designed by Intel, 

20 AMD and National in order to run some form of low-level encryption, and it can also use 

a TPM-like module for additional encryption. Microprocessors and supporting chipsets 
that implement Palladium may support a trusted execution mode that allows 
cryptographically authenticated programs access to a separate memory area. Such 
microprocessors may be equipped with a security coprocessor, which stores a unique pair 

25 of cryptographic keys in a non-volatile memory. Such a microprocessor and coprocessor 

may then be combined to create a motherboard that implements Palladium functionality. 
A corresponding software component, called the Trusted Operating Root, works in 
conjunction with the microprocessor and its coprocessor. The Trusted Operating Root 
running on the microprocessor and the coprocessor are configured to encrypt data in such 

30 a way tiiat no other combination of Trusted Operating Root and coprocessor would be 

able to decrypt it. 

The above security technologies are indeed promising but they require specific 
hardware that may take several years to be proven and to justify using them in gaming 
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teiminals. Furthennore, there may always persist a lingering distrust of such large 
corporate software providers such as, for example, Microsoft. Consequently, game 
regulators tend to hold back the deployment of such technologies, thereby discouraging 
the early adoption of networked multimedia software technologies as q^plied to the 
heavily regulated gaming industry. 

SUMMARY OF THE INVENTION 

There is no better alternative for casinos and lotteries gaming computer hardware 
but to adopt standard PC hardware controlled by the latest generation multimedia 
software from Microsoft, QNX, WindRiver Systems, Unix or from the Linux 
community. It is, therefore, an object of this invention to provide additional security 
mechanisms that can perform indq)endent and trusted verification of the Commercial- 
Off-The-Shelf (COTS) software installed on the gaming terminals that can be trusted 
because of its precisely defined objectives and the availability of source code for pe^ 
review and certification by gaming certification labs. 

Gaming terminals, gaming kiosks and lottery terminals are hereafter collectively 
referenced as gaming machines, for ease of reference. 

The most promising approach available today in a COTS multimedia product that 
offers comprehensive security for preventing unauthorized code from executing, is 
integrated in Microsoft Windows XP, Windows 2000 and Windows .NET. There are 
three technologies that address three different layers; namely, (1) Driver Signing, (2) 
Windows File Protection and (3) Software Restriction Policies. These three technologies 
cover all but two aspects of possible execution by unauthorized modified software code, 
that is, (1) by modification of the motherboard BIOS or other add-on boards such as a 
graphic card with on-board BIOS or a SCSI controller with dedicated on-board BIOS, 
(2) by modification of an emulated CPU such as downloadable microcode for the 
Transmeta microprocessor that emulates Intel CPU instructions. The risk with the 
emulated CPU instructions can be simply avoided by not allowing the use of such 
emulating microprocessors. It is, therefore, another object of this invention to provide a 
trusted mechanism to verify that the motherboard BIOS and add-on BIOS are not 
unauthorized. It is a fiirther object of this invention to provide a trusted mechanism to 
verify memory content, hardware register content and any form of data storage media. 
Verification, according to embodiments of the present invention, relies on a hash 
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signature or on code signing with a trusted certificate. 

It is to be noted that the present invention covers the prevention of execution of 
unauthorized software but not the authentication of users and processes that are handled 
by the standard Access Control List (ACL) of the operating system. 

According to one embodiment tiiereof, the present invention is a method for a 
gaming terminal to authorize execution of downloaded software, comprising the steps of 
running in the gaming machine a version of Microsoft Windows operating system having 
Software Restriction Policy capability, and setting the Software Restriction Policy to 
authorize execution of software code-signed with a certificate from a designated trusted 
party. 

The running step may run a version of Microsoft Windows operating system 
having System File Protection capability. The running step may run a version of 
Microsoft Windows operating system having Driver Signing capability. The method 
may further include the step of setting the Microsoft Driver Signing policy to only 
authorize execution of drivers code-signed with a certificate from Microsoft. A step of 
setting the Microsoft Driver Signing poUcy to only authorize execution of drivers that are 
code-signed with a certificate from at least one of Microsoft and a designated trusted 
party may also be carried out The running step may run a version of Microsoft 
Windows operating system having System File Protection and Driver Signing 
capabilities. The gaming machine may include a microprocessor and the microprocessor 
and the operating system in the running step may collectively implement Microsoft's 
PaUadium (or an equivalent) fimctionality. The operating system in the running step 
may be a Microsoft Windows operating system that, together with the microprocessor, 
implements Microsoft's Palladium, Windows File Protection and Driver Signing 
capabiUties or like fimctionalities. The gaming machine may include a motherboard and 
the operating system in the running step may be a version of Microsoft Windows 
operating system that, together with the motherboard, implements capabilities specified 
by the Trusted Computing Platform AlHance (TCPA) or similar fimctionalities. The 
gaming machine may include a microprocessor and the operating system in the running 
step may be a version of Microsoft Windows operating system that, together with the 
microprocessor, implements TCPA, System File Protection or Windows File Protection 
and Driver Signing. 

According to another embodiment thereof, the present invention is also a method 
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for a gaming terminal to authorize execution of downloaded software, comprising the 
steps of; running an operating system that may include a configurable functionality for 
restricting code execution to code that has been signed by a designated trusted party, and 
configuring the restricting functionality to only authorize execution of software that is 
code-signed with a certificate from the designated trusted party. 

Ite restricting fimctionality may conform to the Microsoft Software Restriction 
Policy, for example. The operating system in tiie running step may be configured to 
prevent a replacement of selected monitored or protected system files with files that do 
not originate from a trusted source. The trusted source may be the same as the 
designated trusted party. The operating system may include Microsoft's System File 
Protection (SFP) or Microsoft's Windows File Protection (WFP), for example. The 
operatmg system in the running step may be configured to only allow execution of 
drivers that have been code-signed with a certificate from a trusted source. The 
operating system may include Microsoft's Driver Signing and the trusted source may be 
Microsoft. The operating system in the niniiing step may be configured to prevent a 
replacement of selected monitored or protected system files with files that do not 
originate from a trusted source, and only allow execution of drivers that have been code- 
signed with a certificate from the trusted source, such as, for example, Microsoft. The 
operatmg system in the running step may incorporate Microsoft's Driver Signing and 
Microsoft's System File Protection (SFP) or Microsoft's Windows File Protection (WFP), 
for example. The gaming machine may include a microprocessor and supporting 
chipsets that, together with the operating system in the running step, implements a 
Palladium-like capability. The machine may include a microprocessor and supporting 
chipsets that, together with the operating system in the running step, implements a 
Palladium-like, System File Protection and Driver Signing capabilities. The gaming 
machine may include a motherboard that, together with the operatmg system in the 
running step, implements capabilities specified by the Trusted Computing Platform 
Alliance (TCP A). The gaming machine may include a microprocessor that, together 
with tile operating system in the running step, implements TCP A, and Microsoft's 
Windows File Protection and Driver Signing. 

According to still another embodiment thereof, the present invention may also be 
viewed as a method for operating a gaming machine, comprising the steps of runnmg an 
operating system loaded in the gaming machine; downloading at least one software 
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module into the gaming machine; checWng a code signature of at least one downloaded 
software module using a trusted verification driver, and authorizing execution of the 
downloaded software module in the gaming machine only if the downloaded software 
module may be successfally verified by the trusted verification driver. 

The runnmg step may run an operating system lhat is configured to prevent Ihe 
replacement of selected monitored or protected system files wilhin the gaming machine 
with files that do not originate from a tmsted source. The running step may run an 
operating system that may include Microsoft's System File Protection (SFP) or 
Microsoft's Windows File Protection (WFP). The operating system m the nmning step 
may causes the authorizing step to authorize execution of the downloaded software 
module only if the downloaded software module has been code-signed with a certificate 
from a trusted source. The running step may run an operating system that may inchide 
Microsoft's Driver Signing and the trusted source may be Microsoft. The downloaded 
software module may include a driver and die method further may include the step of 
setting a Microsoft Driver Signing policy to cause the authorizing step to only authorize 
execution of drivers that are code-signed with a certificate from Microsoft. The method 
may fiuther include the step of setting a Microsoft Driver Signing policy to cause tiie 
authorizing step to only authorize execution of drivers that are code-signed with a 
certificate fiom Microsoft and/or a designated trusted source. The operating system in 
the rmming step may be a Microsoft Windows operating system that includes System 
File Protection and/or Driver Signing capabilities. The gaming machine may include a 
microprocessor that, together with' the operating system in die nmning step, implements 
Microsoft's Palladium capabihiy or similar capabilities from otiier vendors. The gaming 
machine may include a microprocessor tiiat. togetiier witti the operating system in the 
nmning stop, implements MicrosofPs Palladium, Windows File Protection and/or Driver 
Signing capabilities, for example. The gaming machmemay inchide a motherboard that, 
togetiier with flie operating system in the running step, implements capabilities specified' 
by tiie Trusted Computing Platform Alliance (TCP A). The operating system in the 
running step maybe a Microsoft operating system, for example. The operating system in 
the running st^ may be a Microsoft operating system implementing TCPA, System File 
Protection or Windows File Protection and/or Driver Signing, for example. The 
operating system in the running step may inchjde the Microsoft Software Restriction 
Policy or a similar functionality fixan another vendor. 
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The present invention may also be viewed as a method for verifying gaming 
tenninal software, comprising the steps of installing at least one driver into the gaming 
machine; taking complete control of the gaming machine with the at least one driver; 
verifying a legitimacy of all software and memory content in the gaming machine; 
relinquishmg control of the gaming machine, and autibtorizing the gaming machine to 
execute only of the software that may be successfully verified. The verification step may 
include a challenge-response step to ensure that the trusted verifier driver has not been 
spoofed and/or that the trusted verifier driver is executing. 

The driver(s) may be configured to execute at the highest machine permission 
level. The taking step may include a step of freezing an operation of the operating 
system of the gaming machine. The taking step may also include a step of disabling 
interrupts on the gaming machine. The verifying step may include verifying a BIOS of a 
motherboard of the gaming machine. The verifying step may include verifying a BIOS 
of any add-on board within the gaming machine. The verifying step may include 
verifying ROM shadowing within the gaming machine, verifying hardware registers, 
verifying a signature in memory of the at least one driver, verifying the content of files 
on disk within the gaming machine and/or verifying the downloadable micro-code of 
smart hardware within the gaming machine, for example. The method may further 
include a step of auditing the source code of the driver(s) by a third party. The source 
code of the driver(s) may also be audited by a game certification lab. The method may 
further include a step of certifying the driver(s) by a game certification lab and/or by a 
third party. The gaming machine may be controlled by a PC, the driver(s) may be code 
signed and the installing step may be triggered by one or more plug-and-play dongles 
inserted in one or more ports of the PC. The driver(s) installed in the installing step may 
be code-signed by Microsoft's WHQL - or another certifying agency, for example. The 
verifying step may verify the legitimacy of the software and memory contents without 
modifying the content thereof and the method further may include a step of reporting an 
outcome of the verifying step. The gaming machine further may include a third party 
dongle installed therein and the driver(s) may be linked to the third party dongle to 
enable the third party to audit the driver(s). The gaming machine further may include a 
hard disk drive that may include a partition formatted for simple file access (by means of 
a FAT, for example) and wherein the method further may include a step of accessing 
code-signed downloaded software fix)m the simple file access partitioned hard disk drive. 
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The hard disk drive partiticm may be fonnatted according to FAT2 protocol, for example. 
TTie verifying step may verify die memory content stored on one or more of the 
foUowfag within the gaming machine: a hard disk drive of the gaming machine, an 
optical memory of the gammg machine, flash memory of the gaming machine, non- 
volatile RAM memory of the gaming machine, ferromagnetic memory of the gaming 

machine, magnetic memory ofthe gaming machine, and/or holographic memory of the 
gaming machine, for example. 

The present invention, according to anoflier embodiment thereof may be seen as a 
gaming machine, comprising: at least one processor; at least one data storage device; a 

plurality ofprocesses spawned by the at least one processor, the processes inchiding 
processing logic for carrying out steps of: running an operatmg system loaded in the 
gaming machine; downloading at least one software module into the gaming machine; 
checking a code signature of at least one downloaded software module using a trusted' 
verification driver, and authorizing execution ofthe downloaded software module in the 
gaming machine only if the downloaded software module may be successfidly verified 
by the trusted verification driver. 

The present invention is also a gaming machine, comprising: at least one 
processor; at least one data storage device; a plurality of processes spawned by the at 
least one processor, the processes including processing logic for carrying out steps of: 
histallmg at least one driver into the gaming machine; taking complete control ofthe 
gaming machine with the at least one driver; verifying a legitimacy of all software and 
memory content in the gaming machme; relinquishing control of the gaming machine, 

and authorizing flie gaming machine to execute only ofthe software that may be ' 
successfidly verified. 



BRIEFDESCRIPTION OF THE DRAWING 

Fig. 1 ilhistrat^ a new game deployment cycle. 
Fig. 2 ilhistrates a conventional code signing process. 
Fig. 3 ilhistrates a conventional code verification process. 
Fig. 4 illustrates an aspect ofthe present invention, in which the code signatare 
verification platform is itself verified. 

Fig. 5 shows simplified layered view ofthe Microsoft security model. 
Fig. 6 ilhistrates proposed Microsoft PaUadium technology . 
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Fig. 7 shows a trusted mechanism for verifying ttie code signing of downloaded 
game software in a gaming machine, according to an embodiment of the present 
invention. 

Fig. 8 shows a first method for trusted verification according to an embodiment 
of the invention. 

Fig. 9 shows second method for trusted verification, according to another 
embodiment of the present invention. 

Fig. 10 shows a third method for trusted verification, according to yet another 
embodiment of the present invention. 

Fig. 1 1 shows an embodiment of the invention using the Microsoft Windows 
Hardware Quality Lab (WHQL) scheme. 

Fig. 12 shows an embodiment of the invention using the Microsoft Driver 
Signing scheme. 

Fig. 13 shows an embodiment of the present invention that uses a disk 
partitioning scheme. 

Fig. 14 shows an embodiment of the invention that uses aplug-and-play dongle 
for the activation of the trusted driver. 

Fig. 15 shows a challenge response sequence according to an embodiment of the 
present invention. 

DETAILED DESCRIPTION OF THE INVENTION 

Reference will now be made in detail to the construction and operation of 
preferred implementations of the present invention illustrated in the accompanying 
drawings. The foUowtag description of the preferred implementations of the present 
invention is only exemplary of the invention. The present invention is not limited to 
these implementations, but may be realized by other implementations. 

A new game deployment campaign whereby one or a plurality of gaming 
machines are to receive a new game is represented in Fig. L The flowchart 100 starts at 
102 when the decision to initiate a project to develop and release a new game is made. 
The game developer 106 develops a new game application 104 whose code must be 
certified at 108 by a recognized certification lab 1 1 0. The certified code must then be 
signed 1 12 by a trusted party 1 14 that is registered with a certificate issuing authority 
(CA) 116. The trusted party 1 14 may be the certification lab 1 10. The signed code is 
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Stored in a library 1 1 8 on a server on a game operator's central system 120. 

When the decision to deploy the new game 122 is taken by the game operator, the 
game terminal(s) enter into a remote download session of the code stored in the library 
124 located in the game operator's central system 120. Prior to downloading, the code 
stored in flie library may be verified for proper code signing to ensm-e the code has not 
been replaced in the library. Upon receiving the downloaded code, the gaming machine 
or terminal 126 executes a program to verify the code signature of the downloaded code, 
as shown at 128. If the downloaded code cannot be trusted, the code is trashed or 
quarantined as shown at 130, 132. If the downloaded code can be trusted (successfully 
passes the verification), it is stored locally in persistent memory in the gaming machine, 
as shown at 130, 134. Persistent memory may include, for example, a hard disk, an 
optical disk, a flash memory, One-Time-Programming (OTP) memory, a magnetic 
memory, a holographic memory and a battery backed-up RAM. 

When the new game is requested to execute the downloaded code, the stored 
signed code is retrieved at 138 and its code signature is verified. If the retrieved 
downloaded code cannot be trusted, the code is trashed or quarantined as shown at 142, 
144. If the retrieved downloaded code can be trusted, it is executed at 142, 146. 

As noted by Eric Fleishman in Code Signing, The Intemet Protocol Journal, 
Volume 5, Number 1, March 2002, code signing is a mechanism to sign executable 
content The phrase "executable content" refers to presenting executable programs in a 
manner so that they could be run locall3^regardless of whether the executable file 
originated locally or remotely. Code signing is commonly used to identify authorship of 
applications distributed via the Intemet. Device drivers can be code signed to inform an 
operating system of the autiiorship of that driver. For example, the device drivers for 
Windows 98/ME/2K/XP operating systems should preferentially be certified by 
Microsoft's device driver certification laboratory. The entity signs the device driver 
executable in order to certify that Ihe device driver in question has indeed been 
successfully demonstrated by a Microsoft certification laboratory to correctly run on that 
operatmg system. Code signing may be applied to other ^e of files; for example 
Microsoft .CAB files. Code signing provides only authenticity and integrity for 
electronic executable files and some other data files - it does not provide user/process 
privacy, authentication, or authorization. 

A signature provides authenticity by assuring users as to where the code 
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came from and who really signed it. If the certificate originated from a trusted third- 
party Certificate Authority (CA), then the certificate embedded in the digital signature as 
part of the code-signing process provides the assurance that the CA has certified that the 
code signer is who he or she claims to be. Integrity occurs by using a signed hash 
function as evidence that the resulting code has not been tampered with since it was 
signed. 

Code signing appends a digital signature to the executable code itself. 
This digital signature provides enough information to authenticate the signer as well as to 
ensure that the code has not been subsequently modified. 

Code signing is an application within a PKI system. A PKI is a distributed 
infrastructure that supports the distribution and management of public keys and digital 
certificates. A digital certificate is a signed assertion (via a digital signature) by a trusted 
third party, known as the Certificate Authority (CA), which correlates a public key to 
some other piece of information, such as the name of the legitimate holder of the private 
key associated with that public key. The binding of this information then is used to 
establish the identity of that individual. All system participants can verify the name-key 
binding coupling of any presented certificate by merely applying the public key of the 
CA to verify the CA digital signature. This verification process occurs without involving 
the CA. 

A pubhc key refers to the fact that the cryptographic underpinnings of 
PKI systems rely upon asymmetric ciphers that use two related but different keys, a 
public key, which is generally known, and a private key, which should be known only by 
the legitimate holder of the public key. 

The certificates used to sign code can be obtained in two ways: They are 
either created by the code signers themselves by using one of the code-signing toolkits or 
obtained from a CA. The signed code itself reveals the certificate origin, clearly 
indicating which alternative was used. The preference of code-signing systems (and of 
the users of signed code) is that the certificates come from a CA, and CAs, to earn the fee 
they charge for issuing certificates, are expected to perform "due diligence" to establish 
and verify the identity of the individual or institution identified by the certificate. As 
such, the CA stands behind (validates) the digital certificate, certifying that it was indeed 
issued only to the individual (or group) identified by the certificate and that the identity 
of that individual (or group) has been verified as stated. The CA then digitally signs the 
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certificate in order to formally bind this verified identity with a given private and public 
key pair, which is logically contained within the certificate itself. This key pair will 
subsequently be used in the code-signing process. 

Code signing may be accomplished as shown in Fig. 2. The signing utiUty uses a 
hash algorithm 212 on the executable code 202,210 to compute a digest 216 (which is 
also known as a one-way hash) by securely compressing executable code 202 of arbitrary 
length into a fixed-length digest result 21 6. Hie most common hash fiinction algorithms 
used in code signing are the Secure Hash Algorithm (SHA), Message Digest Algoriffam 4 
(MD4), or MD5. Hie resulting length of the digest is a fiinction of the hash fiinction 
algorithm, but a common digest length is 128 bits. The digest 216, 218 is then encrypted 
220 using the trustee's private key 222. 224. The encrypted digest 226,228 and the 
trustee's digital certificate 230. 232, 234 are thesn appended to the executable code 
202.204. 208 to form the signed code 206. The certificate 230, 234 contains the trastee's 
public key 231. 

The private key is kept in a secure place by the trustee to prevent code signing of 
fiaudulent code by an unknown party. 

Code-signing verification is accomplished as shown in Fig. 3. Verification of the 
signed code 302 may be done for example when the gaming machine retrieve the stored 
game code before executing it 140 as shown in Fig. 1. The verification software inspects 
the signed code 302 to verify the authenticity and integrity of the received executable 
code 3 10. The verification is done in the following manner. 

1. Step 1 (308): The certificate 304 is examined 306, 308 to verily that it is 
recognizable as a correctly fomiatted certificate, that it originates from a trusted party 
(the trustee) and that it also contains 309 a conectly formatted pubhc key 336 of the 
trustee. If not, the process feils. 

2. Step 2 (318): If it is, the certificate 304 identifies the hash function 
algorithm 212 that was used to create the signed digest 216 within the received signed 
code 206, 302. With this information, the same hash algorithm code 320 that was used to 
create the original digest 216 is then applied to the received executable code 310. 3 12, 
314, creating a digest value 322, 324, which then is temporarily stored. 

3. Step 3 (338): The digital signature 326 (or encrypted digest value) is then 
taken 328,330 flxMn the signed code 302 and decrypted 332, 334 with the code signer's 
(the trustee's) public key 336 (pubUc key is contained in certificate 304, 308, 309), 
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revealing the digest value 342, 344, which was originally computed 216 by the trustee 
signing the code with its private key 222. Failure to success&lly decrypt this signed 
digest value 326 indicates that flie code signer's private key was not used to create the 
received signature. If this is the case, then that signature is a fraud and the code-signing 
verification process fails. 

4. Step 4 (346): The recomputed digest 324 of Step 2 is then compared 348 
to the received digest 326 that was decrypted 344 in Step 3 . If these two values are not 
identical, then the code has subsequently been modified m some way and the code- 
signing verification process fails. If the digests 324 and 344 are identical, then the 
identity of the code sigaer (the trustee) is established. 

There is a dilemma in the code-signing verification process 300, however, in that 
the process itself might be a firaudulent verification process. Consequently, it is a 
necessary to be able to verify that the verification platform can be trusted. The code 
verification processes 128 and 140 may advantageously be replaced by the process 
according to the present invention, as shown in Fig. 4, The code-signmg verification 400 
starts at 402 by verifying that the code-signing verification platform can be trusted, as 
shown at 404, 410. If not, then an alert 408 is raised and the overall process fails. If trust 
can be established as shown at 410, then the code-signing verification can be safely 
executed, as indicated at 412. If the code-signing verification detects an anomaly as 
shown at 414, 416, then an alert 418 is raised and the overall process fails. If the code- 
signing verification succeeds at 420, flien the process returns 422 to the main flow 100 as 
shown in Fig. 1. 

Then, again, can we trust that the verification process that verifies that the code 
signing verification platform can be tmsted? Consequently, according to the present 
invention, all the iterative inner levels of verification processes must be examined until 
the lowest possible level where trust cannot reasonably be conq)romised. 

A simplified layered view of the Microsoft security model can be examined on 
the diagram shown at 500 in Fig. 5, The computer hardware 502 is controlled directly via 
the motherboard BIOS 504, the add-on card BIOS 506, the Hardware Abstraction Layer 
(HAL) 512 and the DirectX 516 services. The motherboard BIOS 504 has interfaces with 
the drivers 508 and the HAL 512. The operating system kernel 510 has interfaces with 
the drivers 508 and the HAL 512 on the lower side, and to the OS services 514 on the 
upper side. The gaming applications 5 1 8 reside on top of the OS services 514. 
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The Software Restriction Policies technology 524 ensures that only code signed 
by trusted parties can execute. The code forming the Software Restriction Policies 
platfi)nn is embedded within the operating system and it can be trusted to execute 
because the Windows FUe Protection technology 522 ensures that flie code is 
unmodified. 

Equivalent technology to Microsoft "Software Restriction Policies" may exist in 
other existing of forthcoming operating systems. Such technologies are generically 
referred to herein as "Software Restriction Policies" regaixiless of the operating system 
supplier (e.g., Microsoft). 

Microsoft's "Software Restriction Policies" support the following four ways to 
identify software: (1) Hash— A cryptographic fingerprint of the file. (2) Certificate— A 
software publisher certificate used to digitally sign a file. (3) Path— The local or 
universal naming convention (UNC) path of where the file is stored. (4) Zone— Internet 
Zone 

As stated by John Lambert of Microsoft Corporation in "Using Software 
Restriction Policies in Windows XP and Windows .NET Server to Protect Against 
Unauthorized Software", January 2002, A hash rule is a cryptographic fingeiprint that 
uniquely identifies a file regardless of where it is accessed or what it is named. 

A certificate rule specifies a code-signing associated with a certificate for 
software developed or certified by trusted parties. Certificates used in a certificate rule . 
can be issued firom a commercial certificate authority (CA) such as VeriSign, a Windows 
2000/Wmdows .NET Server PKI, or a self-signed certificate. A certificate rule is a 
strong way to identify software because it uses signed hashes contained in the signature 
of the signed file to match files regardless of name or location. 

A path rule can specify a folder or fiilly qualified path to a program. When a path 
rule specifies a folder, it matches any program contained in that folder and any programs 
contained in subfolders. Both local and UNC paths are supported. 

Zone Rule. A rule can identify software fi-om the Internet Explorer zone fi-om 
which it is downloaded. These zones are: Ihtemet, hitranet, Restricted Sites, Trusted 
Sites, My Computer. Currently this applies to only Windows Installer (*.MSI) packages. 
It does not apply to software downloaded in Ihtemet Explorer. 

Wmdows File Protection technology (WFP) protects system files by running in 
the background and detecting attempts to replace protected system files. WFP is 
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triggered aft^ it leceives a directory change notification on a file in a protected 
directory. Once this notification is received, WFP determines which file was changed. If 
the file is protected, WFP looks up ttie file signature in a catalog file to determine if the 
new file is the correct Microsoft version. If it is not, the operating system replaces &e 
file with the correct version firom Uie dllcache directory or the distribution media. 

Equivalent technology to Microsoft "Windows File Protection" technology may 
exist in other existing of forthcoming operating systems. Such technologies are 
generically referred to herein as "Systems File Protection" regardless of the operatmg 
system supplier (e.g., Microsoft). 

WFP serves the goal of maintaining a stable, reliable and secure operating system 
by preventing replacement of certain monitored system files except by trusted sources, 
such as service pack installations or Windows Update. 

After detecting the replacement of a protected file, WFP searches for the replaced 
files in the following order: (1) Search the dllcache directory. (2) If the system was 
installed via network install, search the network install path. (3) Search on the CD. In the 
context of the gaming machine, only (1) and (2) would be applicable. 

WFP uses Driver Signing to verify files. The code forming the Windows File 
Protection (WFP) or System Protection File (SFP) platform is embedded within the 
operating system inner layers and it can be trusted because the Driver Signing 
technology 520 guards against unknown drivers that may introduce fi-audulent code. 

As stated in "Digital Signature Benefits for Windows Users", Copyright © 2001 
Microsoft Corporation, Driver Signing serves the goal of maintaining a stable reliable 
and secure operating system, A driver's digital signature allows the systeni to ensure that 
the driver files bemg installed have not been modified since the files passed testing by 
Microsoft Windows Hardware Quality Lab (WHQL). Depending on the Driver Signing 
policy in effect on a user's system, the user might be allowed to disregard warnings and 
install an unsigned driver. 

Equivalent technology to Microsoft "Driver Signing" technology and WHQL 
scheme may exist in other existing of forthcoming operating systems. Such technologies 
are generically referred to herein as 'TDriver Signing" regardless of the operating system 
suppher (e.g. , Microsoft). 

It is however easy to recognize that a gap exists between the above-described 
Driver Signi ng technology and deeper levels, which may allow firaudulent code to run. 
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For exann>le, fraudulent code may be introduced in the motherboard BIOS or tiie add-on 
board BIOS. Li a same mamier, frauduleait code may be introduced in micro-coded 
hardware wherein micro-code is changeable. None of flie Microsoft technologies 
described above would protect against such intrusions. 

Microsoft has recently announced (June 2002) a technology code-named 
"Palladium" that addresses llie concerns raised in flie previous paragraph. 

Microsoft Palladium tedinology may be viewed at 600 in Fig. 6. Palladium 
requires that a forthcoming specially designed microprocessor (by AMD, Intel, or other 
CPU manufacturer) and siq)porting chipsets be mounted in the computer hardware 602 in 
which special hardwired or downloadable secure micro-code and security devices are 
incorporated 628. In particular, a tamper-resistant secure cryptographic co-processor is 
required but it is not clear at this stage if it would be buried inside the microprocessor, 
inside the chipsets or if it would be a separate component. Secure RAM memory may 
also be required. It is anticipated that any of Ihese configurations may be supported by 
Palladium. 

PaUadium's changes to the CPU would allow it to be placed into a new mode 
where certain areas of memory are restricted via a technique called "code curtaining" to 
an ultra-privUeged piece of code called the "nub" or "TOR". ("Nub" is the Palladium 
team's term for this code, and "TOR", for "Tmsted Operating Root", is the official pubUc 
term.) The nub is a kind of trusted memory manager, which runs with more privilege 
than an operating system kernel. The nub also manages access to the cryptographic co- 
processor. 

It is not clear at this stage to what level Palladium extends as suggested at 632 
and 633, but it is likely that (his will at least bridge the gap with the Driver Signing layer 
620. The PaUadram software code 630 cooperates with the security devices buried within 
the microprocessor and other secure devices embedded on the computer board to provide 
a trusted base for everything that executes on higjier levels. 

The alternative a^jroach is the Trusted Computing Platfonn Alliance (TCPA), 
whose specification was finalized in January 2001, calls for the creation of a Tiiisted 
Platform Module (TPM) that requires a discrete cryptographic processor 626 residing on 
the PCs motherboard 602 fliat contains a unique digital signature. Microsoft Palladium 
technology 630 is csipable of supporting the TCPA specification when a TCPA security 
device 626 resides on the motherboard. 
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Although Palladium is marketed as a 'Digital Right Management" (DRM) 
platform, it offers sophisticated advanced security technologies. The capability to 
support DRM insures that the resulting expected volume of sales would be significant 
enough to justify Microsoft and microprocessor vendors to work together and invest 
development budgets. Failure to succeed will enormously benefit vendors who offer 
specialized devices ttiat guaranty DRM such as Sony DVD players and Game 
PlayStation. It is therefore clear that the capability to offer DRM in PCs is a matter of 
survival for companies such as Microsoft, Intel, AMD and National. 

Palladium enabled PCs would offer an ideal secure software and hardware 
platfomi for gaming terminals. However, this requires specific hardware that may take 
several years to be proven and to justify using tiiem in gaming machines. Furthennore, 
there may always remain lingering distrast of large software companies and the 
standards fliey promulgate. Equivalent technology to Microsoft code-name "Palladium" 
technology may exist in other existing of forthcoming operating systems. Such 
technologies are generically referred to herein "Palladium-like" regardless of the 
operating system supplier (e.g., Microsoft). 

TCPA enabled PCs would also offer a good hardware platform and some TCPA 
compliant security devices are akeady available (ATMEL AT90SP0801 and EMBASSY 
fi-om Wave Systems Corp). However, wide adoption by motherboard manufacturers and 
availability of proven software support for Windows is not assured. 

Equivalent technology to 'TCPA*' technology may exist in other existing of 
forthcoming operating systems, security integrated circuits and motherboards. Such 
technologies are generically referred to herein *TCPA-like" regardless of the operating 
system supplier (e.g., Microsoft) and the hardware supplier. 

Palladium is the Microsoft code-name for a secure technology that requires 
specific hardware and software applicable for PCs and other computer devices such as 
mobile phones and hand-held PC. Especially, the microprocessor dice is adapted to 
incorporate deeply buried security devices and only special super-trusted (ultra- 
privileged) software mode can access to ttiese buried devices. Although Microsoft and its 
partners (Intel, AMD, etc. . .) will make available to the public the complete Palladium 
specification and source code, it is not clear whether this technology will be 
implemented for other operating system platform such Linux, Unix, Wind River, QNX, 
etc. . . There may be restriction issues and patent issues that may prevent industry-wide 
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acceptance of PaUadium. It is therefore anticipated that competing technology, although 
not specifically designed for DRM (Digital Right Management), may become available 
that addresses the same security concem, that is, to operate fiom a hyper-trusted based 
that depends on d^ply buried security devices not easily accessible without very 
expensive equipment means. For simplicity of reading, such competing technology is 
called 'Talladium-lilffi" hereafter. 

It is, therefore, a further object of this invention to provide a trusted mechanism 
that does not require a special hardware security device in order to verify the code- 
signing of the downloaded game software. 

A trusted mechanism for verifying the code signing of downloaded game 
software in a gaming machine according to an embodiment of the present mvention is 
represented in Fig. 7. The various elements shown in Fig. 7 that bear the same label 
correspond to the identically labeled elements in Fig. 6 and the description thereof is 
omitted here for the sake of brevity. Fig. 7 inchides, however, a driver named "trasted 
verifier", referenced at numeral 702. Drivers are a special class of software components 
that are capable of accessing the totality of the hardware resources 710 of the computer. 
When provided by third parties for controlling the add-on hardware that they sell that can 
be added to the computer, such as a SCSI hard disk controller and a graphics card for 
example, the third party drivers (a part of 704) are notorious for creating system 
instabilities and crashes. Furthermore, drivers may introduce fraudulent code that cannot 
easily be detected or protected against. Fortunately, "script kiddies" that are notorious 
for releasing countless variants of viruses on the hitemet generally do not have the 
specific knowledge required to develop new "driver viruses". However, a very 
determined software developer specialized in the coding of drivers may at any time take 
advantage of this latent opportunity. The same applies to the motherboard BIOS 706 and 
the add-on board BIOS 708 (one or a plurality of add-on boards and dieir associated 
BIOS), especially BIOS stored in Flash memory that can be downloaded from the 
Mtemet, or BIOS that is copied &oia slow access ROM memory to fast RAM (this 
technique is known as "ROM shadowing"). Nowadays, the BIOS for the motherboard 
and add-on boards, as weU as the firmware for hard disk drives, CD-ROM Writers, and 
other mtelligent peripheral devices can be updated, either manually or automaticaUy, 
using software code downloaded fi»m die hitemet 

Microsoft does not supply and control an entire computer hardware with aU its 
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hardware peripherals (which is called a closed platfonn)^ as Sim Microsystems and 
Apple do and has had an extremely tough job of making the operating system run 
reliably because of fliese third party provided drivers. To resolve this issue, Microsoft 
has recently introduced a 'Driver Signing" technology to prevent drivers of unknown 
origin from executing and creatmg undesirable instabilities. The aforementioned WHQL 
scheme has been setup whereby third party vendors send their driver executable code to 
the WHQL that will be extensively subjected to advanced code profiling to ensure that 
the code obeys a number of specific rules, so as to prevent it to function erratically. Upon 
successful completion of the test and qualification, the driver executable code is signed 
with a Microsoft certificate. Consequently, if the operating system policy is configured 
to accept only Microsoft signed drivers, the operating will prevent the execution of all 
non-Microsoft signed drivers. 

Although Microsoft has set up this scheme for preventing drivers of unknown 
origin fi-om executing, such Driver Signing does not guarantee that the driver code has 
no latent fraudulent code in it. 

A preferred embodiment of the invention takes advantage of the capabilities of 
drivers (Microsoft, Linux, Unix or others operating systems) to let the 'Trusted Verifier" 
driver 702 take full control of the computer controlling the gaming machine in order to 
operate security verifications independently of the operating system and also to ensure 
that the code-signing verification process can be trusted The driver source code can be 
made available for peer review and for certification by a gaming certification lab. The 
"Trusted Verifier" driver complies with the mles dictated by the operating system and 
usually a DDK Device Driver Kit is made available by the operating system supplier to 
help software developers develop their own device drivers. A device driver or simply 
driver may control a hardware device or no hardware devices. In the later case, the driver 
is commonly known as a "resident" program or pseudo driver. 

In addition, the 'Trusted Verifier" driver 702 may be submitted to Microsoft 
WHQL in order to obtain a driver that is code-signed with a Microsoft certificate. 
Consequently, the Windows operating system that is controlling the gaming machine 
computer may be built with the highest security allowed by the three Microsoft 
technologies "Driver Signing", "Windows File Protection" and "Software Restriction 
Policies". 

Having the 'Trusted Verified driver 702 signed by Microsoft WHQL ensures 
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that when the highest security policy for drivers is activated, the Trusted Verifier driver 
may not have been fi-audulently changed subsequent to being certified by WHQL. The 
verification is performed when the driver is loaded for execution by the Windows 
operating system. Microsoft WHQL may require that a specific hardware device be 
connected to the PC in order for flie "Trusted Verifier*' to be installed and be activated. 
In that case, a simple pluggable hardware device 1406 (Fig. 14) such as a Universal 
Smal Bus (USB) dongle, a keyboard dongle, a mouse dongle or a printer port dongle 
compliant with the Plug-And-Play standard may be designed to allow the operating 
system to install the "Trusted Verified' driver associated to hardware device. 

A preferred embodiment of the invention may use a first method for trusted 
verification such as depicted in Fig. 8. It is assumed that the "Trusted Driver*' has been 
successfully installed by the operating system as described in the previous paragraphs, 
either as a signed driver or as an unsigned driver, in the case of a recent version of 
Microsoft Windows operating system (standard or embedded version) or equivalent 
operating system featuring the signed drivers technology, or a generic driver in the case 
of Unix, Linux, QNX and other operating systems. 

The Verify Code Signature process 128 and 140 in Fig. 1 may execute as shown 
in diagram 800. The method starts at 802, whereupon the Trusted Verifier driver 
execution is entered at 804, which gains full control of the computer 806. To gain fiill 
control of the computer, the driver may run at the highest system permission and may 
first disable all interrupts to prevent preemption by high priority processes. Indeed, 
keeping all interrupts disabled prevents all other process fi*om operating, which 
effectively fi:eezes the operating system. Watchdogs may need to be refreshed in order 
to avoid a hardware restart signal or reset signal to restart the machine. Some functions 
may no longer be accessible such as the hard disk, which requires the interrupts to 
operate. However, some minimum access functionality may be achieved by running low 
level disk access, for example via the hard disk controller BIOS or tbe hardware 
controller chipset (the moth^board BIOS, whose source code can be licensed, contains 
all the necessary low level routines to access and control all the low level fimctions of 
the motherboard). Thereafter, ttie driver may verify the motherboard BIOS at 808, add- 
on Card BIOS at 816 as well as verify other areas such as RAM memory content, storage 
memory content and hardware registers as shown at 824, which are each compared with 
a trusted reference. Ofparticular importance is the verification ofliie RAM memory 
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areas taken by the Trusted Verifier driver itself while it is executing, in order to compare 
its signature with a trusted reference to insure that no virus or other fraudulent code is 
attached. If any of the verification 808, 816, 824 fails, as shown at 810, 818, 826, an 
alert is raised, as shown at 812, 820 and 828, respectively. The alert may trigger a 
predetennined operation such as flashing the red light on the gaming machine towo: and 
preventing furflier operation of the gaining machine while displaying or logging a 
relevant error message. If all the verifications are successfiil as shown at 814, 822, 830 
then the driver re-enables the interrupts at 832, and exits the Trusted Verifier Driver at 
834. 

The exiting 834 of the Trusted Verifier driver indicates that the lower 
components of the software platform and of the hardware platform are trusted and that 
consequently, higher level secure technologies such as Driver Signing, System File 
Verification and Soflware Restriction Policy are executing on a trusted base. Utilities 
associated to Software Restriction Policy and Authenticode such as "Chktrust.exe" may 
be executed to verify whether the code-signing of the downloaded soflware (at 836) can 
be trusted. If not, as shown at 838, an alert 840 may trigger a predetermined operation 
such as flashing the red light on the gaming machine tower and prevents further 
operation of the gaming machine while displaying or logging a relevant error message. If 
the verification is successful at 842, then the process is allowed to end at 844. 

A preferred embodiment of the invention may use a second method for tmsted 
verification such as depicted in Fig. 9. It is assumed that the 'Trusted Driver" has been 
successfully installed by the operating system as described in the previous paragraphs, 
either as a signed driver or as an unsigned driver in the case of a recent version of 
Microsoft Windows operating system (standard or embedded version) or equivalent 
operating system featuring the signed drivers technology, or a generic driver in the case 
of Unix, Linux, QNX and other operating systems. 

While performing a game deployment cycle and downloading new game 
software in the gaming machines as shown in Fig. 1, the "Verify Code Signature" 
process 128 and 140 is further detailed in diagram 900. 

The method starts at 902, whereupon the Trusted Verifier driver execution is 
entered at 904 and gains fiiU control of the computer at 906. To gain full control of the 
computer, the driver may run at the highest system permission and may first disable all 
interrapts to prevent preemption by high priority processes* Keeping all interrupts 
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disabled indeed prevents all other process fiom operating, and consequently the 
operating system is fix)zen. Watchdogs may need to be refreshed in order to avoid a 
hardware restart signal or reset signal to restart the machine. Some functions may no 
longer be accessible such as the hard disk that requires the intenrupts to operate. 
However, some minimum access functionality may be achieved by running low level 
disk access, for example via the hard disk controller BIOS or the hardware controller 
chipset (the motherboard BIOS, whose source code can be licensed, contains all the 
necessary low level routines to access and control all the low level functions of the 
molbeiboard). Thereafter, the driver may verify the motherboard BIOS at 908, the add- 
on BIOS at 916 as well as verify other areas such as RAM memory content, storage 
memory content and hardware registers at 924, which are each compared with a trusted 
reference. Of particular importance is the verification of the RAM memory areas taken 
by the Trusted Verifier driver itself while it is executing, in order to compare its 
signature with a trusted reference to insure that no virus or other firaudulent code is 
attached. If any of the verifications at 908, 916, 924 fail at 910, 918, 926, an alert is 
raised at 912, 920, 928, respectively. The alert would trigger a predetermined operation 
such as flashing the red light on the gaming machine tower and preventing further 
operation of the gaming machine while displa3ring or logging a relevant error message. 

If all die verifications are successful at 914, 922, 930, this indicates that the lower 
components of the software platform and of the hardware platform are trusted and that 
consequently, higher-level secure verification can be trusted A process may be executed 
to verify whether the code signing of the downloaded software at 932 can be trusted. If 
not, as shown at 934, an alert 936 may trigger a predetermined operation such as flashing 
the red light on the gaming machine tower and prevents further operation of the gaming 
machine while displaying or logging a relevant error message, for example. If the 
verification is successful at 938, then the downloaded software can be trusted. The 
driver may the re-enable Ihe interrupts and release full control of the computer at 940. 
The Trusted Verifier driver may liien be exited at 942 and the method ends at 944. 

Process flow 900 differs fi:om process flow 800 in that the verification of the 
code signatmre of the downloaded code 932 is performed within the Tmsted Verifier 
driver and not at a higher level by the operating software. This can be seen in the 
diagram as process 932 is perfi)rmed before the releasing of the full control of the 
computer and the re-enabling of the interrupts. In order for the Trusted Verifier driver to 



wo 2004/004855 



PCT/US2002/029927 



23 

be able to verify the code-signing of the downloaded software, the code-signed software 
downloaded may have to be stored in storage memory that allows such access from the 
driver. This issue is ftirther discussed relative to Fig. 13. 

A preferred embodiment of the invention may use a third method for trusted 
verification such as depicted in Fig. 10. It is assumed that the 'Trusted Driver" has been 
successftilly installed by the opa:ating system as described in the previous paragraphs, 
either as a signed driver or as an unsigned driver in the case of a recent version of 
Microsoft Wmdows operating system (standard or embedded version) or equivalent 
operating system featuring the signed drivers technology, or a generic driver in the case 
of Unix, Linux, QNX and other operating systems. 

While performing a game deployment cycle and downloading new game 
software in flie gaming machines as shown in Fig. 1, the ''Verify Code Signature" 
process 128 and 140 is fiirther detailed in diagram 1000. The method begins at 1002 and 
the Trusted Verifier driver execution is entered at 1004, which gains fiiU control of the 
computer, as shown at 1006. To gain foil control of the computer, the driver may run at 
the highest system permission and may first disable all interrupts to prevent preemption 
by high priority processes. Keeping all interrupts disabled prevents all other process from 
operating, which effectively freezes the operating system. Watchdogs may need to be 
refreshed in order to avoid a hardware restart signal or reset signal to restart the machine. 
Some functions may no longer be accessible such as the hard disk that requires the 
interrupts to operate. However, some minimum access fimctionality may be achieved by 
running low level disk access, for example via the hard disk controller BIOS or the 
hardware controller chipset (the motherboard BIOS, whose source code can be licensed, 
contains all the necessary low level routines to access and control all the low level 
ftinctions of the motherboard). The driver may then verify the motherboard BIOS at 
1008, the add-on BIOS at 1016 as well as verify other areas such as RAM memory 
content, storage memory content and hardware registers 1024, which are each compared 
with a trusted reference. Of particular importance is the verification of the RAM 
memory areas taken by the Trusted Verifier driver itself while it is executing, in order to 
compare its signature with a trusted reference to insure that no virus or other fraudulent 
code is attached. If any of the verification 1008, 1016, 1024 faUs at 1010, 1018, 1026, an 
alert is raised at 1012, 1020, 1028. The alert may trigger a predetermined operation such 
as flashing the red li^t on the gaming machine tower and preventing further operation 
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of the gaming machine while displaying or logging a relevant error message, for 
example* 

If all the verifications are successful at 1014, 1022, 1030, this indicates that the 
lower components of Ihe software platform and of the hardware platform are trusted and 
that consequently, higher-level secure verification can be trusted, A process may be 
executed to verify whether the operating system components 1032 can be trusted. This 
maybe done by accessing the operating system files on the system storage media and by 
verifying their hash or code-signature with certificate against a trusted reference. 
Success at 1038 indicates that the operating sj^tem can be trusted, as no unauthorized 
modification has been detected. 

A process maybe executed to verify whether the code-signing of the downloaded 
software can be trusted, as shown at 1040. If not, as shown at 1042, an alert 1044 may 
trigger a predetermined operation such as flashing the red light on the gaming machine 
tower and prevents fiirther operation of tiie gaming machine while displaying or logging 
a relevant error message. If the verification is successful at 1046, then the downloaded 
software can be trusted. 

The driver may the re-enable the interrupts and release full control of the gaming 
machine's computer at 1048. Thereafter, the Trusted Verifier driver is exited 1050 and 
the method ends at 1052. 

The process flow 1000 differs from process flow 900 in that the Trusted 
Verification driver performs a verification of the operating system components 1032 
agaiast a trusted reference. In order for the Tmsted Verifier driver to be able to verify the 
operating system components, necessary access mechanisms to the files must be 
available. Software to access files on FAT16 or FAT32 formatted disk partitions is quite 
common. Software to access files on advanced disk partitions such as Microsoft NTFS is 
less common. Examples of third party products that are capable of accessing NTFS files 
mdependently of Microsoft Windows operating system are Partition Magic from 
PowerQuest Corp, www.powerquest.com and Partition Ck)mmander from V 
Communications, Inc. (www.v-com.com). Source code for allowing NTFS file access is 
available on the Internet from various freelance developers. In addition, Microsoft is 
making available the source of its operatmg system to selected developers. 

A preferred embodiment of the invention may use Microsoft Windows Hardware 
Quality Lab (WHQL) scheme 1000 depicted in Fig. 1 1, As shown, the method starts at 
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1 102 and the vendor or developer submits the driver executable code and auxiliary data 
to Microsoft WHQL at 1 104. The Microsoft WHQL performs driver code analysis and 
testing at 1006 to verify the conformity of the driver's code with a set of rules. If the 
testing 1 108 fails at 1 110, the software is returned to the vendor at 1 1 12, along with the 
test reports. however, flie WHQL testing is successful as shown at 1 1 14 then the 
driver is code-signed with a Microsoft Digital Signature at 1 1 16. The code-signed driver 
is sent to flie vendor/developer or alternatively is published on the Windows Update 
server at 1 1 1 8 for any user connected to Internet to access tijrough the Microsoft 
Windows Update technology. 

A prefeired embodiment of the invention may use Microsoft Driver Signing 
scheme 1200 depicted in Fig. 12. In the description tiiat follows, the Driver Signing 
policy 1200 is set up to accept only Microsoft code-signed drivers. The method starts at 
1202. When a new hardware device is detected in the gaming machine and identified by 
its Plug-and-Play identifier by the Windows operating system, the corresponding driver 
is retried fiom storage at 1204 and its code-signing is examined at 1206. If, at 1208, it is 
detemiined that the code-signing is not valid or that the certificate is not firom Microsoft, 
as shown at 1210, an alert 1212 is activating that may log the failure and abort the driver 
installation. If, however, the code-signing is determined to be valid and the certificate is 
from Microsoft at 1214, then the driver may be loaded in memory at 1216 and the driver 
may be executed at 1218. Usually, when a driver is first installed, only its initialization 
strategy segment is executed. The body of the driver is executed subsequently when the 
hardware device needs to communicate with the application. The method ends at 1220 

A preferred embodiment 1300 of the invention may use a disk partitioning 
scheme 1302 as depicted in Fig. 13, In order to facUitate access to the downloaded code- 
signed game fi-om the Trusted Verifying driver, the downloaded code-signed game 
software files may advantageously be stored in a disk partition having a simple file 
format such as FAT16 or FAT32. The disk 1304 may have two partitions 1306 and 1320. 
Partition 1306 may be formatted in the NTFS file format, and partition 1320 may be 
formatted in the FAT32 file format. Partition 1306 may contain the operating system 
1310, some applications 13 12 and some data files 1314. Partition 1320 may contain the 
downloaded code-signed game 1316 and some encrypted or signed data 1318. 

It is to be noted that strong encryption of the downloaded game files would not 
present any benefit as tiiere is not requirement to keep secret the content of the file. The 
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objective is to ensure tiiat files have not been fraudulently modified, therefore visibility 
of or easy access to the game files for reading or even writing is not a significant 
concCT. Ease of access to files for performing code-signing audit from a trusted process 
such as die Trusted Verifier driver is highly advantageous in order to detect fraud. 
5 When a trusted verification process is available, it is significantly easier to detect 

fiaudulent code prior to its execution than to prevent someone from introducing 
fi:audulent code somewhere amongst the gigantic storage disk space, by numerous 
means, and at unpredictable times. Once fraudulent code has been detected, forensic 
analysis may eventually allow tracking down and prosecuting the suspect EfiBcient and 

10 reliable code-signing verification means may offer strong deterrence. 

A preferred embodiment 1400 of the invention may use a plug-and-play dongle 
for the activation of the trusted driver as depicted in Fig. 14. Fig. 14 shows a gaming 
machine or device 1402 that incorporates a PC 1404, Having the 'Trusted Verifier" 
driver 702 signed by Microsoft WHQL ensures that when the highest security policy for 

15 drivers is activated, the Trusted Verifier driver may not have been fraudulently changed 

subsequent to being certified by WHQL. The verification is performed when the driver is 
loaded for execution by the Windows operating system. Microsoft WHQL may require 
that a specific hardware device 1406 be connected to the PC 1404 that controls the 
gaming machine 1402 in order for the 'Trusted Verifier*' to be installed and be activated. 

20 In that case, a simple pluggable hardware device 1406 such as a USB dongle, a keyboard 

dongle, a mouse dongle or a printer port dongle compliant with the Plug-And-Play 
standard may be designed to allow the operating system to install the "Trusted Verifier" 
driver associated to hardware device. The pluggable hardware device may not perform 
any useful function apart from implementing a compliant Plug and Play interface, and 

25 may be constructed using for example a low-cost PICMicro USB family 8-bit 

microprocessor from Microchip (www.Microchip.com). 

To ensure that the Trusted Verifier has indeed executed and has not been spoofed 
(i.e. replaced by a non authorized counterfeit program), a challenge-response controlled 
by the central system may advantageously be implemented. A challenge-and-response is 

30 a common authentication technique whereby some secret information is verified in a 

response torn a given challenge. For any of the Trusted Verifier driver scenarios 
depicted of Fig 8, 9 and 10, an additional challenge-response step 1501 maybe added as 
shown on Fig. 15. 
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The Trusted Verifier drivCT execution is entered at 1504, which gains full control 
of the computer at 1506. To gain full control of die computer, the driver may run at the 
highest system permission and may first disable all interrupts to prevent preemption by 
high priority processes. Keeping all interrupts disabled indeed prevents all other process 
5 from opeiatmg, and consequently the operating system is frozen. Watchdogs may need 

to be refreshed in order to avoid a hardware restart signal or reset signal to restart the 
machine. Some functions may no longer be accessible such as netwoifc conununication 
that requires the interrupts to operate. However, some minimum access functionality may 
be achieved by running low level network communication, for example via the Ethernet 
1 0 network controller chipset (source code can be licensed that contains all the necessary 

low level routines to access and control all the low level functions of the Eth^et 
network card). 

A notification at 1508 may be sent by the driver via the commimication network 
(or a special out-of-boimd port) to the central server (or altematively to an audit device) 

15 to inform that the Trusted Verifier driver is executing. The Trusted Verifier waits until it 

receives a reply from the central server (or altematively the audit device) at 1510 
containing a challenge message produced by the central server (or altematively the audit 
device). The Trusted Verifier driver computes a response corresponding to the challenge 
message according to a predetermined secret algorithm at 1512. A response, shown 

20 atl5 14 is sent to the central server (or altematively to the audit device) via the 

communication network (or a special out-of-bound port). After step 1514, the Trusted 
Verifier may not engage in further dialog with the central server (or altematively to the 
audit device) via the communication network (or a special out-of-bound port). 

Then the driver may verify the compute platform at 1516 (motherboard BIOS, 

25 add-on BIOS, RAM memory content, storage memory content, hardware registers, 

etc.). Ifthe compute platform verification at 1516 fails, as shown at 1518, an alert is 
raised at step 1520. The alert would trigger a predetermined operation such as flashing 
the red light on the gaming terminal tower and preventing further operation of the 
gaming terminal while displaying or logging a relevant error message. If all the 

30 verifications are successful at 1522, then the driver re-enables the intermpts at 1524 and 

exits at 1526. 

Independentiy upon receiving the response from the Trusted Verifier driver at 
step 1514, the central server (or altematively the audit device) compares the response 
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received with the expected successful response. If ftie received response does not match 
the expected response, the central server raises an alert for immediate action or for 
forensic analysis. If the response matches the expected response, the event is logged for 
later analysis to ensure that the Trusted Verifier has executed as expected, by checking 
for example against the activity log of games played. 

Periodically, the activity log of games played is examined against the log of 
Trusted Verifier responses firom the associated gaming terminal. If case of a missing 
entry or missing entries in the log, spoofing of the Trusted Verifier driver may be 
suspected. 

A special audit device may be used instead of the central syst^ to control the 
challenge-response authentication. The special audit device may be connected to the 
standard Ethernet port or to an out-of-bound communication port whereby the data 
traffic is not mixed with nomaal network traffic. The out-of-bound port may be an 
additional Ethernet card, a serial port, a wireless port, a USB port, a wireless 
communication port, an Infra-Red port or any other port capable of exchanging data. 

Although specific embodiments have been illustrated and described herein, it will 
be appreciated by those of ordinary skill in the art that any arrangement that is calculated 
to achieve the same purpose may be substituted for the specific embodiments shown. 
This application is intended to cover any adaptations or variations of the present 
invention. 

For example, those of ordinary skill in the art will appreciate that various 
combination of the technologies to solve the digital rights management problem or 
altematively the hyper-trusted base problem may be derived depending on the exact 
computing environment Furthemiore, those of ordinary skill in the art will recognize 
that the invention can be practiced on a large scale although illustrated herein with only a 
single gaming terminal. For example, the gaming terminal may comprise secure 
hardware processing means mcluding multi-general-purpose processors (i.e. "Palladium" 
compliant Intel Pentium CPU) and other secure specialized processors (i.e. graphic co- 
processor, network co-processor, etc.) spanning within or in the vicinity of the gaming 
terminal. 

The terminology used in this application with respect to is meant to include all 
hardware and software configuration and all networked environments. For example, 
processor may mean tiie microprocessor (i.e. Intel Pentium), the motherboard, the 
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computer, the processing hardware, a PC or a plurality of PCs coxnmimicating together. 
Moreover, the processing hardware is not limited to Intel x86 computer architecture (i.e. 
may be based on ARM or StrongARM architecture). Therefore, it is manifestly intended 
that this invention is not to be limited only by the following claims and equivalents 
5 thereof. 

CONCLUSIONS 

The invention offers a secure game download platform for updating gaming 
machines software and games as well as additional security verification at low level 

10 independently of the opeiatmg system. This way, the rehictance to trust the products of 

large software manufacturers such as Microsoft may be overcome. This invention may 
be seen as security tool, whose source code can be audited by peers, in order to verify 
Microsoft's operating system, for example. As noted above, when a trusted verification 
process is available, it is significantly easier to detect fraudulent code prior to its 

15 execution than prevent someone to introduce fraudulent code somewhere amongst the 

gigantic storage disk space, by niunerous means, and at unpredictable times. Once 
firaudulent code has been detected, forensic analysis may eventually allow tracking down 
and prosecuting the suspect. Efficient and reliable code-signing verification means may 
. offer strong deterrence. Consequently, game regulators that are holding back on 

20 allowing the early adoption of networked multimedia software technologies may feel 

more comfortable in adopting such technologies. 



wo 2004/004855 



30 



PCT/US2002/029927 



CLAIMS 

1 . A method for a gaming termmal to aufliorize execution of downloaded 
software, comprising the steps of: 

running in the gaming machine a version of Microsoft Windows operating system 
having Software Restriction Policy capability, and 

setting the Software Restriction Policy to authorize execution of software code- 
signed with a certificate from a designated trusted party, 

2. The method of claim 1, wherein the running step runs a version of 
Microsoft Windows operating system having System File Protection capability. 

3 . The method of claim 1 , wherein the running step runs a version of 
Microsoft Windows operating system having Driver Signing capabiUty. 

4. The method of claim 3, further comprising the step of: 

setting the Microsoft Driver Signing policy to only authorize execution of drivers 
code-signed with a certificate from Microsoft. 

5 . The method of claim 3, further comprising the step of: 

setting the Microsoft Driver Signing poHcy to only authorize execution of drivers 
that are code-signed with a certificate from at least one of Microsoft and a designated 
Ousted party. 

6. The method of claim 1 , wherein the running step runs a version of 
Microsoft Windows operating system having System File Protection and Driver Signing 
capabilities. 

7. The method of claim 1, wherein the gaming machine includes a 
processing hardware and wherein the processing hardware and the operating system in 
the runnmg step collectively implement Microsoft's Palladium capability. 

8. The method of claim 1 , wherein the gaming machine mcludes a 
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processing hardware and wherein the operating system in the running step is a Microsoft 
Windows operating system that, together with the processing hardware, implements 
Microsoft's Palladium, Windows File Protection and Driver Signing capabilities. 

9. The method of claim 1, wherein the gaming machine includes a 
processing hardware and wherein the operatmg system in the running step is a version of 
Microsoft Windows operating sj^tem that, together with the processing hardware, 
implements capabilities specified by tiie Trusted Computing Platform Alliance (TCPA). 

. 10. Hie metliodofclaiml,wherem the gaming machine includes a 
processing hardware and wh^em the operating system in the running step is a version of 
Microsoft Windows operating system that, together with the processing hardware, 
implements TCPA, Systeni File Protection or Wmdows File Protection and Driver 
Signing. 

11. A method for a gaming terminal to authorize execution of downloaded 
software, comprising the steps of: 

running an operating system that includes a configurable policy functionality for 
restricting code execution to code that has been signed by a designated trusted party; 

configuring the restricting policy fimctionality to only authorize execution of 
software that is code-signed with a certificate firom the designated trusted party. 

12. The method of claim 11, wherein the restricting policy functionality 
conforms to the Microsoft Software Restriction Policy. 

13. The method of claim 1 1, wherein the operating system in the running step 
is configured to prevent a replacement of selected monitored or protected system files 
with files that do not originate firom a trusted source. 

14. The method of claim 13, wherein the trusted source is the designated 
trusted party. 

15. The method of claim 13, wherein the operating system includes one of 
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Microsoft's System File Protection (SFP) and Microsoft's Windows File Protection 
(WFP). 

1 6. The method of claim 1 , wherein the operating system in the running step 
is configured to only allow execution of drivers that have been code-signed with a 
certificate firom a trusted source. 

17. The method of claim 16, wherein the operating system includes 
Microsoft's Driver Signing and wherein the tmsted source is Microsoft. 

1 8. The method of claim 1 1 , wherein the operating system in the running step 
is configured to: 

prevent a replacement of selected monitored or protected system files witti files 
that do not originate firom a tmsted source, and 

only allow execution of drivers that have been code-signed with a certificate, firom 
the tmsted source. 

1 9. The method of claim 1 8, wherein the tmsted source is Microsoft. 

20. The method of claim 1 8, wherein the operating system in the running step 
incorporates Microsoft's Driver Signing and one of Microsoft's System File Protection 
(SFP) and Microsoft's Windows File Protection (WFP). 

21v The method of claim 1 1, wherein the gaming machine includes a 
processing hardware that, together with the operating system in the miming step, 
implement a Palladium-like capability. 

22. The method of claim 1 1, wherein the gaming machine includes a 
processing hardware that, together with the operating system in the running step, 
implements a Palladium-like, System File Protection and Driver Signing capabilities. 

23. The method of claim 1 1, wherein the gaming machine includes a 
processing hardware that, together with the operating system in the running step. 
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implements c^abilities specified by the Trusted Computing Platform Alliance (TCPA). 

24. The method of claim 1 , wherein the gaming machine includes a 
processing hardware that, together with the operating system in the running step, 
implements TCPA, and Microsoft's Windows File Protection and Driver Signing. 

25. A method for operating a gaming machine comprising the steps of: 
running an operating system loaded in the gaming machine; 
downloading at least one software module into the gaming machine; 
checking a code signature of at least one downloaded software module using a 

trusted verification driver, and 

authorizing execution of the downloaded software module in the gaming machine 
only if the downloaded software module is successfiiUy verified by the trusted 
verification driver. 

26. The method of claim 25, wherein the running step runs an operating 
system that is configured to prevent a replacement of selected monitored or protected 
system files within the gamingWchine with files that do not originate firom a trusted 
source. 

27. The method of claim 25, wherein the running step runs an operating 
system that is configured to prevent the execution of selected monitored or protected 
system files within the gaming machine for files that do not originate firom a trusted 
source. 

28. The method of claim 25, wherein the running step runs an operating 
system whose capability includes one of Microsoft's System File Protection (SFP) and 
Microsoft's Windows File Protection (WFP). 

29. The method of claim 25, wherein the operating system in the running step 
causes the authorizing step to authorize execution of the downloaded software module 
only if the downloaded software module has been code-signed with a certificate firom a 
tmsted source. 
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30. The method of claim 29, wherein the rmming step runs an operating 
system that includes Microsoffs Driver Signing and wherein the trusted som'ce is 
Microsoft 

3 1 . The method of claim 29, wherein the running step runs an operating 
system that includes Microsoft's Driver Signing. 

32. The method of claim 30, wherein the downloaded software module 
includes a driver and wherein the method fiirfliCT comprises the step of: 

setting a Microsoft Driver Signing policy to cause the authorizing step to only 
authorize execution of drivers that are code-signed witti a certificate from one of 
Microsoft and a trusted source. 

33 . The method of claim 25, further comprising the step of: 
setting a Microsoft Driver Signing policy, 

and authorizing the installation and execution of the tmsted verification driver 
subsequent to verifying that it is code-signed with a certificate ft'om a trusted source. 

34. The method of claim 32a, wherein the trusted source is Microsoft. 

35. The method of claim 30a, further comprising the step of: 

setting a Microsoft Driver Signing policy to cause the authorizing step to only 
authorize execution of drivers that are code^signed with a certificate from at least one of 
Microsoft and a designated tmsted source. 

36. The method of claim 25, wherein the operating system in the running step 
is a Microsoft Windows operating system configured with Software Restriction Policy, 
Windows File Protection and Driver Signing 

37. The method of claim 25, wherein the gaming machine includes a 
processing hardware that, together with the operating system in the running step, 
implements Microsoft's Palladium capability. 
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38. The method of claim 25, wherein the operating system in the running step is a 
Microsoft Windows operating system configured with Software Restriction Policy, 
Windows File Protection and Driver Signing and wherein the gaming machine includes a 
processing hardware that, together with the operating system in die running step, 
implements Microsoft's Palladium capability. 

39. The mediod of claim 25 i^erein the gaming machine includes a 
processing hardware that, together with the operating system in the running step, 
implements Microsoft's Palladium, Software Restriction Policy, Windows File Protection 
and Driver Signing capabilities. 

40. The metihod of claim 25, wherein the gaming machine includes a 
processing hardware that, together with the operating system in the running step, 
implements c^abilities specified by ttie Trusted Computing Platform Alliance (TCP A). 

41 . The method of claim 40, wherein the operating system in the running step 
is a Microsoft operating system. 

42. The method of claim 25, wherein the operating system in the running step 
is a Microsoft operating system implementing TCPA, Software Restriction Pohcy, 
Windows File Protection and Driver Signing. 

43. The method of claim 25, wherein the operating system in the running step is a 
Microsoft Windows operating system configured with Software Restriction Policy, 
Windows File Protection and Driver Signing and wherein the gaming machine includes a 
processing hardware that, together with the operating system in the running step, 
implements the Trusted Computing Platform Alliance (TCPA) specification. 

44. The method of claim 25, wherein the operating system in the running step is a 
an operating system configured with Software Restriction Policy, System File Protection 
and Driver Signing and wherein the gaming machine includes a processing hardware 
that, together with the operating system in the running step, implements Palladium-like 
capability. 
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45. The method of claim 25, wherein the gaming machine includes a processing 
hardware that, together with the operating system in the running step, implements 
Palladium-like capability. 

46. The method of claim 25, wherein the operating system in the running step is a 
Microsoft Windows operating system configured with Software Restriction Policy, 
Windows File Protection and Driver Signing and wherein the gaming machine includes a 
processing hardware that, together with the operating system in the running step, 
implements Palladium-like capability. 

47. A method for verifying gaming terminal software, comprising the steps 

of: 

installing at least one driver into the gaming machine; 
taking complete control of the gaming machine with the at least one driver, 
verifying a legitimacy of all software and memory content in the gaming 
machine; 

relinquishing control of the gaming machine, and 
authorizing the gaming machine to execute only of the software that is 
successfully verified. 

48. The method of claim 47, whereby the at least one driver is configured to 
execute at a higjiest machine permission level. 

49. The method of claim 47, wherein the talcing step includes a step of 
freezing an operation of the operating system. 

50. The method of claim 47, wherein the taking step includes a step of 
blocking the execution of the operating system. 

5 1 . The method of claim 47, wherein the taking step includes a step of 
disabling interrupts on the gaming machine. 
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52. The method of claim 47, wherein the verifying step includes verifying a 
BIOS of a motherboard of the gaming machine. 

53. The method of claim 47, wherein the verifying step includes verifying a 
BIOS of any add-on board within the gaming machine. 

54. The method of claim 47, wherein the verifying step includes verifying 
ROM shadowing within the gaming machine. 

55. ^ Themethodof claim 47, wherein the verifying step includes verifying 
hardware registers. 

56. The method of claim 47, wherein the verifying step includes verifying a 
signature in memory of the at least one driver. 

57. The method of claim 47, wherein the verifying step includes verifying a 
content of files on disk within the gaming machine. 

58. The method of claim 47, wherein the verifying step includes verifying a 
downloadable micro-code of smart hardware widiin the gaming machine. 

59. The method of claim 47, wherein the verifying step includes verifying a 
downloadable firmware of a smart hardware within the gaming machine. 

60. The method of claim 47, further comprising the step of auditing a source 
code of the at least one driver by a third party. 

61 . The method of claim 47, further comprising the step of auditing a source 
code of the at least one driver by a game certification lab. 

62. The method of claim 47, further comprising the step of certifying the at 
least one driver by a game certification lab. 
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63. The method of claim 47, fiirfher comprising toe step of code-signing with 
a certificate the at least one driver by a game certification lab. 

64. The mefliod of claim 47, further comprising the step of certifying the at 
least one driver by a third party. 

65. The method of claim 47, further comprising the step of code-signing with 
a certificate the at least one driver by a third party. 

66. The method of claim 47, wherein the gaming machine is controlled by a 
PC, wherein the at least one driver is code signed and wherein the installing step installs 
the code-signed driver, the mstalling step being triggered by at least one plug-and-play 
dongle inserted in at least one port of the PC. 

67. The method of claim 47, wherein the at least one driver installed in die 
installing step is code-signed by Microsoft's WHQL. 

68. The method of claim 47, wherein the verifying step verifies the legitimacy 
of the software and memory contents without modifying a content thereof and wherein 
the method further includes a step of reporting an outcome of the verifying step. 

69. The method of claim 47, wherein the verification step includes a 
challenge-response step to ensure that the trusted verifier driver has not been spoofed. 

70. The method of claim 47, wherein the verification step includes a 
challenge-response step to ensure that the trusted verifier driver is executing. 

71. The method of claim 47, wherein the gaming machine further includes a 
tiiird party dongle installed therein and wherein flie at least one driver is linked to the 
third party dongle to enable the ttiird party to audit the at least one driver. 

72. The method of claim 47, wherein the gaming machine further includes an 
interfece for a dongle compliant with the Microsoft plug and play specification and 
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wherein the at least one driver is installed or activated when the dongle is plugged-in. 

73 . The method of claim 47, wherein the gaming machine further includes a 
hard disk drive that includes at least one partition formatted for simple file access and 
wherein the method fiirther includes a step of accessing code-signed downloaded 
software from the at least one simple file access partitioned hard disk drive. 

74. The method of claim 73, wherein the hard disk drive partition is formatted 
according to FAT32 protocol. 

75. Hie method of claim 73, wherein the hard disk drive partition is formatted 
according to a predetermined file format protocol. 

76. The method of claim 47, wherein the ganoing machine further includes a 
plurality of hard disk drives wherein at least one hard disk drive contains at least one 
partition formatted for simple file access and wherein the method further includes a step 
of accessing code-signed downloaded software from the at least one partition formatted 
for simple file access. 

77. The method of claim 73, wherein the at least one partition is formatted 
according to FAT32 protocol. 

78. The method of claim 73, wherein the at least one partition is formatted 
according to a predetermined file format protocol. 

79. The method of claim 47, wherein the verifying step verifies the memory 
content or a trusted signature of the memory content stored on at least one of: 

a hard disk drive of the gaming machine, 
an optical memory of the gaming machine, 
flash memory of the gaming machine, 
non-volatile RAM memory of the gaming machine, 
registers of integrated circuits of the gaming machine, 
ferromagnetic memory of the gaming machine, 
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magnetic memory of the gaming machine^ 
ROM memory of the gaming machine, 
OTP mraiory of the gaming machine, 
holographic memory of the gaming machine, and 
firmware of a smart peripheral. 

80. A gaming machine, comprising: 
at least one processor; 

at least one data storage device; 

a plurality of processes spawned by flie at least one processor, the processes 
including processing logic for carrying out steps of: 

running an operating system loaded in the gaming machine; 

downloading at least one software module into the gaming machine; 

checking a code signature of at least one downloaded software module 
using a tmsted verification driver, and 

authorizing execution of the downloaded software module in the gaming 
machine only if the downloaded software module is successfully verified by the trusted 
verification driver. 

81. The gaming machine of claim 80, wherein the running step runs an 
operating system that is configured to prevent a replacement of selected monitored or 
protected system files within the gaming machine with files that do not originate &om a 
trusted source or that are not consistent with the authorized version of the operating 
system. 

82. The gaming machine of claim 80, wherein the running step runs a 
Microsoft operating system configured with Windows File Protection (WFP). 

83. The gaming machine of claim 80, wherein the operating system in the 
running step causes the authorizing step to authorize execution of the downloaded 
software module only if the downloaded software module has been code-signed with a 
certificate from a trusted source. 
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84. The gaining machine of claim 83, wherein (he running step runs a 
Microsoft operating system configured with Driver Signing and wherein the trusted 
source is Microsoft. 

85. The gaming machine of clahn 83, wherein the running step runs a 
Microsoft operating system configured with Driver Signing. 

86. The gaming machine of claim 80, wherein tiie downloaded software 
module includes a driver and wherein flie method fiirther comprises the step of: 

setting a Microsoft Driver Signing policy to cause the authorizing step to only 
authorize execution of drivers that are code-signed with a certificate Scorn Microsoft. 

87. The method of claim 84, ftirther comprising the step of: 

setting a Microsoft Driver Signing policy to cause the authorizing step to only 
authorize execution of drivers that are code-signed with a certificate from at least one of 
Microsoft and a designated trusted source. 

88. The gaming machine of claim 80, wherein the operating system in the 
running step is a Microsoft Windows operating system configured with Windows File 
Protection and Driver Signing. 

89. The gaming machine of claim 80, wherein the operating system in the 
running step is a Microsoft Windows operating system configured with Software 
Restriction Policy, Windows File Protection and Driver Signing. 

90. The gaming machine of claim 80, wherein the gaming machine includes a 
processing hardware that, together with the operating system in the running step, 
implements Microsoft's Palladium capabiUty. 

91 . The gaming machine of claim 80, wherein the gaming machine includes a 
processing hardware that, together with the operating system in the running step, 
implements Palladium-like capability. 
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92. The gaming machine of claim 80, wherein the gaming machine includes a 
processing hardware that, together wifli the operating system in the running step, 
implements Microsoft's Palladium, SoJftware Restriction Policy, Windows File Protection 
and Driver Signing capabilities. 

93 . The gaming machine of claim 80, wherein the gaming machine includes a 
processing hardware tiiat, together with the operating system in the running step, 
implements Microsoft's Palladium, Windows File Protection and Driver Signing 
capabilities. 

94. The gaming machine of claim 80, wherein the gaming machine includes a 
processing hardware that, together with the operating system in the running step, 
implements capabilities specified by the Trusted Computing Platform Alliance (TCPA). 

95. The gaming machine of claim 80, wherein the gaming machine includes a 
processing hardware that, together with the operating system in the running step, 
implements capabilities specified by the Trusted Computing Platform Alliance (TCPA), 
Software Restriction Policy, System File Protection and Driver Signing. 

96. The gaming machine of claim 80, wherein the gaming machine includes a 
processing hardware that, together with a Microsoft operating system in the r unnin g step, 
implements capabilities specified by the Trusted Computing Platform Alliance (TCPA), 
Software Restriction Policy, Windows File Protection and Driver Signing. 

97. The gaming machine of claim 94, wherein the operating system in the 
running step is a Microsoft operating system. 

98. The gaming machine of claim 80, wherein the operating system in the 
running step is a Microsoft operating system implementing TCPA, Software Restriction 
Policies, Windows File Protection and Driver Signing. 

99. The gaming machine of claim 80, wherein the operating system in the 
running step is a Microsoft operating system implementing TCPA, Windows File 
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Protection and Driver Signing. 

1 00. The gaming machine of claim 80, wherein the operating system in the 
running step includes the Software Restriction Policy capability. 

101. A gaming machine, comprising: 
at least one processor, 

at least one data storage device; 

a plurality of processes spawned by the at least one processor, the processes 
including processing logic for carrying out steps of: 

installing at least one driver into the gaming machine; 

taking complete control of the gaming machine with the at least one 

driver; 

verifying a legitimacy of all software and memory content in the gaming 

machine; 

relinquishing control of the gaming machine, and 
authorizing the gaming machine to execute only of the software that is 
successfiiUy verified. 

1 02. The gaming machine of claim 101, whereby the at least one driver is 
configured to execute at a highest machine permission level. 

103. The gaming machine of claim 101, wherein the taking step includes a step 
of freezing an operation of the operating system. 

1 04. The gaming machine of claim 101, wherein the taking step includes a step 
of blocking the operation of the operating system. 

105. The gaming machine of claim 101, wherein the taking step includes a step 
of disabling interrupts on the gaming machine. 

106. The gaming machine of claim 101, wherein the verifying step includes 
verifying a BIOS of a motherboard of the gaming machine. 
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107. The gaming machine of claim 101, wherein the verifying step inchides 
verifying a BIOS of any add-on hoard within the gaming machine. 

108. The gaming machine of claim 101, wherein the verifying step includes 
5 verifying ROM shadowmg within the gammg machine. 

109. The gamingmachine of claim 101, wherein the verifying step includes 
verifying hardware registers. 

10 110. The gaming machine of claim 101, wherein the verifying step includes 

verifying a signature in memory of the at least one driver. 

111. The gaming machine of claim 101, wherein the verifying step includes 
verifying a content of files on disk within the gaming machine. 

15 

112. The gaming machine of claim 101, wherein the verifying step includes 
verifymg a downloadable micro-code of smart hardware within the gaming machine. 

113. The gaming machine of claim 101, wherein the verifying step includes 
20 verifying a downloadable firmware of a smart hardware within the gaming machine. 

1 1 4. The gaming machine of claim 101, further comprising the step of auditing 
a source code of the at least one driver by a third party, 

25 115. The gaming machine of claim 101, further comprising the step of auditing 

a source code of the at least one driver by a game certification lab. 

1 16. The gaming machine of claim 101, furdier comprising the step of 
certifying the at least one driver by a game certification lab. 

30 

1 17. The gaming machine of claim 101, further comprising the step of code- 
signing with a certificate the at least one driver by a game certification lab. 
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1 18. The gaming machine of claim 101, further comprising the step of 
certifying the at least one driver by a third party. 

1 19. The gaming machine of claim 101, fiirther comprising the st^ of code- 
signing with a certificate the at least one driver by a third party. 

120. The gaming machine of claim 101, wherein the processing hardware 
forms part of a PC that is configured to control the gaming machine and wherein the 
gaming machine further includes a plug and play dongle inserted in at least one port of 
the PC, and wherein the at least one driver is code signed and wherein the installing step 
installs the code-signed driver, the installing step being triggered by the at least one plug- 
and-play dongle. 

121. The gaming machine of claim 101, wherein the at least one driver 
installed in the installing step is code-signed by Microsoft's WHQL. 

122. The gaming machine of claim 101, wherein the verifying step verifies the 
legitimacy of the software and memory contents without modifying a content thereof and 
wherein the plurality of processes include a process to report an outcome of the verifying 
step. 

123. The method of claim 101 , wherein the verification step includes a 
challenge-response step to ensure that the trusted verifier driver has not been spoofed. 

124. The method of claim 101, wherein the verification step includes a 
challenge-response step to ensure that the trusted verifier driver is executing. 

125. The gaming machine of claim 101, wherein the gaming machine further 
includes a third party dongle installed therein and wherein the at least one driver is linked 
to the third party dongle to enable the third party to audit the at least one driver. 

1 26. The gaming machine of claim 101, wherein the gaming machine fiirther 
includes an interface for a dongle compliant with the Microsoft plug and play 
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Specification and wherein the at least one driver is installed or activated when the dongle 
is plugged-in. 

127. The gaming machine of claim 101, wherein the gaming machine further 
includes a hard disk drive that includes at least one a partition formatted for simple file 
access and wherein the plurality of processes include a process to access code-signed 
downloaded software from the at least one simple fde access partitioned hard disk drive. 

128. The gaming machine of claim 127, wherein flie hard disk drive partition is 
formatted according to FAT32 protocol. 

129. The gaming machine of claim 127, wherein the hard disk drive partition is 
formatted according to a predetermined file format protocol. 

130. The gaming machine of claim 101, wherein the gaming machine further 
includes a plurality of hard disk drives wherein at least one hard disk drive contains at 
least one partition formatted for simple file access and wherein the method further 
includes a step of accessing code-signed downloaded software from the at least one 
partition formatted for simple file access. 

131. The gaming machine of claim 128b, wherein the at least one partition is 
fonnatted according to FAT32 protocol. 

132. The gaming machine of claim 1 28b, wherein the at least one partition is 
formatted according to a predetermined file format protocol. 

133. The gaming machine of claim 101, wherein the verifying step verifies the 
memory content or a trusted signature of the memory content stored on at least one of: 

a hard disk drive of the gaming machine, 
an optical memory of the gaming machine, 
flash memory of the gaming machine, 
non-volatile RAM memory of the gaming machine, 
registers of integrated circuits of the gaming machine, 
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ferromagnetic memory of the gaming machine, 
magnetic memory of the gaming machine, 
ROM memory of the gaming machine, 
OTP memory of the gaming machine, 
hologr^hic m^ory of the gaming machine, and 
firmware of a smart peripheral. 

134. A method for a gaming terminal to authorize execution of downloaded 
software, comprising the steps of: 

running in the gaming machine a version of an operating system having Software 
Restriction Policy capability, and 

setting the Software Restriction Policy to authorize execution of software code- 
signed with a certificate from a designated trusted party. 

135. The method of claim 134, wherein the running step runs a version of the 
operating system having System File Protection capability. 

136. The method of claim 134, wherein the running step runs a version of the 
operating system having Driver Signing capability. 

137. The method of claim 135, further comprising the step of: 

setting the Driver Signing policy to only authorize execution of drivers that are 
code-signed with a certificate from a designated trusted party. 

1 38. The method of claim 1 34, wherein the running step runs a version of the 
operating system having System File Protection and Driver Signing capabilities. 

139. The method of claim 134, wherein the gaming machine includes a 
processing hardware and wherein the processing hardware and the operating system in 
the running step collectively implement Palladium-like capability. 



140. The method of claim 134, wherein the gaming machine includes a 
processing hardware and wherein the operating system in the running step is an operating 
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system that, together with the processing hardware, implements Palladium-like, System 
File Protection and Driver Signing capabilities. 

141 . The method of claim 1 34, wherein the gaming machine includes a 
processing hardware and wherein the operating system in the running step is a version of 
an operating system that, together with the processing hardware, inq>lements capabilities 
specified by the Trusted Computing Platform Alliance (TCPA). 

142. The method of claim 135, wherein the gaming machine includes a 
processing hardware and wherein the operating system in the running step is a version an 
operating system that, together wifli the processing hardware, implements TCPA, System 
File Protection and Driver Signing. 



wo 2004/0(14855 



PCT/US2002/029927 



1/13 




116 



108 



112 



Develop New Game Application 



Certily Code 



118 



Sign Code 



106 

L By Game 
J Developer 

By ^ 

Certification 

Ub 



By Trusted 



j^Party 



NO 



122 
124 



128 




Store Signed Code into a Library 



Deploy a new Game ? 



YES 



E 



> 



> 



Remote Download Code from Library 



\ 



114 

By Game 
Operator's 
Central 
System 

120 



132 

^ 130 Hm 

/ 4rashor ^ no^ ><" 
Quarantine Cod^ /^ 



Verify Code Signature 



1 



Trust Code ? 



134 



138 



YES 



E 



store Signed Code 



140 



Retrieve Stores Signed Code 



144 



^ trash or \^ 
Xpuarantine Cod^ 



142 

. NO 



126 

X By Gaming 
/ Machine 



Verify Code Signature 




Trust Code ? 



146 




YES I 



> 



Execute Code 



Tig. 1 



>VO 2004/004855 



PCT/US2002/029927 



2/13 





y/0 2004/0048SS 



PCT/US2002/029927 



3/13 



408 406 



' Alert ^ 



402 



404 



400 



NO 



Can the Code Signature Verification 
Platfomi be Trusted? 



412 
418 416 



410- 



414 



YES 



Verify Code Signature of Downloaded Code 



Code Signature OK ? 





YES 






1 


r 


^422 



> 



Tig. 5 

((Prior Art) 



Software 
Restriction 
Policies^ 

524 



Windows / 
File \ 
Protection 

522 

Drivers 
Signing 

520 



516 
512 



X 

a 



500 



Gaming Applications 



OS Services 



OS Kernel 



HAL 



Drivers 




Mottierboard 
BIOS 



Add-On 
Card , 
BIOS 



Hardware 



^ 518 

^ 514 

.510 

^ 508 
504 

^506 
^502 



wo 2004/004855 



4/13 



PCT/US2002/029927 



600 



Software 
Restriction 
Policies. 

624 



Windows 

File 
Protection 

622 

Drivers 
Signing 



632 



620' 



Palladium / 
& ^ 
TCPA 



630 




IVIotherboard 
BIOS 



Add-On 

Card ^ 
BIOS 



Palladium 




TCPA 


CPU Secure 


Hardware 


Security 


Microcode 




Device ^ 








\ ^ 

628 


602 



606 



626 



Tig. 6 

((Prior Alt) 



wo 2004/0U48S5 



5/13 



PCT/US2002/029927 



m 



Gaming Applications 



OS Services 



OS Kernel 



£ 

Q 



HAL 



Drivers 



Trusted 
Verifier 



Motherboard 
BIOS 



Add-on 
Card 
BIOS " 



Hardware 



wo 2004/004855 



PCT/US2002/021>927 



6/13 



802 — 



Start 



804 



806 



812 



810 808. 



818 816 



814 < 



( Alert "') ^ ^° < ^ Veril 

824 

826 V 

828 ^ V. ^-v. 



YES 



Veriiy Add-on Card BIOS - OK ? 



822 



YES 



Verify Additional Areas 
(memory, registers, etc.) - OK ? 



830 



832 



834 



YES 



Release Full Control of Computer 
(enable interrupts) 



Exit Trusted Verifier Driver 



840 



838 



836 



Alert 



NO 



Verify Code Signature of 
Downloaded Code - OK ? 



Tig. 8 



End 





r 


Enter Tmsted Verifier Driver 






. Tal<e Full Control of Computer 
(disable ail interrupts) 


>x \ ■ ' 


f 



Alert ^ y *—^^^-^< ^ Motherboarel BIOS - OK ? ^ 



> 



842 




^YES 


844 ^ 







wo 2004/004855 



PCT/US2002/029927 



7/13 



902 



Start 



904 



906 



912 



910 908. 





r 


\ 

Enter Trusted Verifier Driver 




r 


Take Full Control of Computer 
(disable all Interrupts) 




r 



Q Alert ^ ^ )^^~^^^^"< ^ Ve"^ MotheriJoarxi BIOS - OK ? ^ 



920 



918 916 



914- 



YES 



Alert ^^y^—^^^-^^ Verify Add-on Card BIOS -OK? ^ 



928 



C 



Alert 




926 924 



NO 



922 



YES 



Verify Additional Areas 
(memory, registers, etc) - OK ? 



936 



934 



932 



930 



Q Alert 



YES 



NO 



Verify Code Signature of 
Downloaded Code - OK ? 



940 



942 



938^ ^ 

} 


YES 

r 


^ Release Full Control of Computer 
(enable interrupts) 




f 


Exit Tmsted Verifier Driver 


944.^^^^ 1 


f 



'Fig. 9 



End 



) 



wo 2004/004855 



PCT/US2002/029927 



8/13 



1004 



1006 



1012 



1010 1008^ 



Alert ") <-g°-<^ 



Verify Motherboard BIOS - OK ? 



1020 



1018 1016 



1014- 



( Alert <^ Veril 



^^YES 



Verify Add-on Card BIOS - OK ? 



1028 



1026 1024 



c 



Alert 




1022 



YES 



NO 



Verify Additional Areas 
(memory, registers, etc) - OK ? 



1036 



1034 1032 



C 



Alert 




1030 



YES 



NO 



Verify Entire Operating System 
-OK? 



1044 



1042 



1040 



1038 



YES 



Verify Code Signature of 
Downloaded Code - OK ? 



1048 



1050 



!FJ^. 10 







\ .... 

Enter Trusted Verifier Driver 






Take Full Control of Computer 
(disable all Interrupts) 


^\ ^ 





> 



> 



1046- ^ 


YES 

r 




Release Full Control of Computer 
(enable interrupts) 


- — ^ 


r 




^ Exit Trusted Verifier Driver 


1052^ 




C End ) 



wo 2UU4/0048S5 



PCT/US2002/029927 



9/13 



1102 



Start 



1104 



1106 



1112 

V 

Return 
Vendor 



1110 



1108 



i to NO 

or y \ 





r 


Submit driver executable code 
and auxiliary data to Microsoft WHQL 




r 


Microsoft WHQL performs 
driver code analysis and testing 




r 



Pass? 



1116 



> 



1118 



1114 




YES 

r 


Microsoft code-sign driver code 
with Digital Signature 






^ Send code-signed driver to Vendor 
or Publish it on the Windows Update server 


1120 




r 


( 


r End ) 



<Fig. 11 



wo 2004/004855 



PCT/US2002/029927 



10/13 



1200 



1202 



1204 



Get driver code from storage 



1206 



1212 ''208 
^^^^ 1210 



Examine Code Signature 



Alert k- 



NO 



<^ Valid Microsoft Digitai Signature ? ^ 



1216 ^ 




1214 ^ 


YES 






Load driver in memory 




1218 






r 




\ 


Execute driver 





1220 



End ) 



'Fig. 12 



V/O 2004/004855 



PCT/US2002/02*K>27 



11/13 



1302 



1300 



/ 



1304 



Hard 
Disk 



\ 



Operating System 



Applications 



Data 



NTFS Partition 



Downioaded Code-Signed Game 



Encrypted Data 



Partition Accessible by 
Trusted Verifier Driver 

(i.e. Fat32 or other format) 



(F/g. 13 



wo 2004/004855 



PCT/US2002/029927 



12/13 



1400 




Tig. 14 



wo 2004/U04855 



PCT/US2002/029927 



13/13 



1502 



1504 



1506 



1508 




1524 



1526 



Start ) 





Enter Trusted Verifier Driver 


} 


f 


Take Full Control of Computer 
(disable all interrupts) 








Send Notification to Server 
(by network) 


y 


f 


Receive Challenge from Server 
(by network) 






Compute Response 


y 


f 


^ Send Response to Server 
(by network) 



'Fig. IS 



Verify Platfonn- OK? 



1522^ 



YES 



1528^ 



End ^ 



> 



-^s^ Release Full Cor 
(enable ii 


itrol of Computer 
iterrupts) 




r 


X - 

Exit Trusted Verifier Driver 



INTERNATIONAL SEARCH REPORT 



International application No. 
PCT/US02/29927 



A. CLASSIFICATION OF SUBJECT MATTER 
IPC(7) : A63P 13/00 
US CL : 713/2 

According to International Patent Classification OPC) or to both national classification and IPC 



B. FIELDS SEARCHED 



Minimuni documentation searched (classification system followed by classification symbols) 
U.S. : 713/1, 2, 188, 200; 705/51, 59; 463/25. 29 



Documentation searched other than mhiimum documentation to the extent that such documents are included in the fields searched 



Electronic data base consulted during the international search (name of data base and» where practicable, search terms used) 
EAST 



POCUMENTS CONSIPEREP TO BE RELEVAm* 



Category * 



Citation of document, with indication, where appropriate, of the relevant passages 



Relevant to claim No. 



X,P 
X,P 

Y 

Y 
Y.P 
X.P 



US 6.330,670 Bl (ENGLAND et al) 11 December 2001 (11.12,2001), see entire document. 

US 6.327.652 Bl (ENGLAND et al) 04 December 2001 (04.12.2001), sec entire document. 

US 5,629,980 A (STEFK et al) 13 May 1997 (13.05.1997), see entire document. 

US 5,715,403 A (STEFIK et al) 03 February 1998 (3.02.1998), see entire document. 

US 6,298,446 Bl (SCHREBER et at) 2 October 2001 (02.10.2001), see entire document. 

Using Software Restriction Policies in Windows XP and Windows .NET Server to Protect 

Against Unauthorized Software 

Microsoft .NET Technical Article. January 2002. 

pages 1-52. 



1-142 
1-142 
1-142 
1-142 
1-142 
1-142 



□ 

Further documents are listed in die continuation of Box C. Q See patent family annex. 



* Spedal categories of cited documents: 

"A* document defining the general state of the art wrhich is not considered to be 
of particular relevance 

"B" earlier application or patent published on or after the International filing date 

'*V' document which may throw doubts on priority ciaim(s) or which is cited to 
establish dw piAUcadon dale of another citation or odier special leason (as 
specified) 

"O" document refeiring to an oral disclosure, use, exhibition or other means 

"P" document published prior to the international filing date but later dian the 
prioriiy date claimed 



later document published after the international filing date or prioriiy 
date and not in conflict with the appllcaibn but dted to ^mdersmnrt the 
principle or dieoiy underlying the Invention 

document of particular relevance; die dalmed invention cannot be 
considered novel or cannot be considered to involve an inventive step 
when the document is fatten alone 

document of particular relevance; die claimed bvention cannot be 
considered to involve an inventive step v^en the document is 
comtrfned with one or more odier such dociimeids, such cambbiation 
being (A)viou5 to a peison sldlled hi the ait 

document menlber of the same patent family 



Date of the actual completion of the international search 
02 December 2002 (02.12.2002) 


Date of mailing of the international search report 

10DtU2O62\ . ^ 


Name and mailing address of the ISA/US 
Commissioner of Patents and Trademarlcs 

Box per 

Washington. D.C 20231 
Facsimile No. (703)305-3230 


Authorized officer // 
Valencia Mardn-Waliace pgral^al Speciafist / 
Telephone No. 703-308-1148 Group3700 



